\subsection{Network Coding Considerations}
\label{Implementation:coding_considerations}
When using \ac{NC}, several options regarding field size, generation size and symbol size, has to be considered. 
Using a low field size is computationally effective, but may cause unnecessary decoding overhead, as described in Section \ref {subsec:codingoverhead}. Although this overhead is practically eliminated when a higher field size is used, the overhead in encoding vectors increases (as described in Section \ref{subsec:datacontainedingeneration}) along with the needed computational power. Due to the time-critical nature of video playback and the smaller overhead in the encoding vectors, the binary field is chosen for the \ac{NC}. This ensures rapid decoding of generations, and the smaller encoding vectors are loosely estimated to make up for the increase in decoding overhead.

The symbol size should be chosen to fit the size of a transmitted network packet. Since 1500 bytes is a common size of the \ac{MTU} of \ac{LAN} \cite{RFC894} and other ethernet networks in general, this is chosen as the upper bound for the size of encoded symbols. Though, because the size of a \ac{GOP} varies, it may be necessary to adjust symbol size and generation size to fit a \ac{GOP} in a generation with as little zero-padding as possible. Zero-padding is needed because the size of a coded generation (in bytes) is definite, when the symbol size and the generation size (in symbols) is decided.

Research papers propose systematic network encoding \cite{NCMOBDEV_09}, where the first packets from a generation is transmitted uncoded, because of the fact that these will always be usable for the receivers. Only the redundancy is transmitted as coded data. Although this greatly reduces the computational power needed to decode a generation, it is not considered directly needed in the implementation, as the goal is to create a proof-of-concept implementation.

All of the above features can be implemented with \verb|kodo|, a \ac{NC} C++ library. \verb|Kodo| is described in Section \ref{implementation:software:externaltools}.
